signal: describe what the OS handler actually writes, and cover duck-typed re group selectors - #1225

Two independent follow-ups from the #1209 review.

signal: the ticker comments named the wrong writer

Three comments — register_ticker, signal_pushback, and the ticker_addr handoff in install_signal_handling — documented the OS signal handler as forcing the ActionFlag ticker negative. It does not. The handler sets the pending bit and arms the eval-breaker's async bit, both lock-free atomics; sync_async_ticker drives the ticker negative later, under the GIL. That split is exactly what keeps the handler async-signal-safe, so the comments now say why the handler must not write that cell.

Comments only; no behaviour change. A reviewer named one of the three sites — the other two carried the same claim.

re: __index__ arm of the group-selector conversion was uncovered

group, __getitem__, start, end, and span take a selector as a number when its type supplies __index__ and as a name otherwise. stdlib_re.py only ever passed literal integers and literal names, so the conversion's __index__ arm — which runs arbitrary Python — was never exercised.

Not included

The review's Critical finding on sre_match_group (an unrooted *const W_SRE_Match held across do_span, which can run arbitrary Python) is refuted. W_SRE_Match is built only by w_sre_match_new → W_SRE_Match::allocate_stable → alloc_in_oldgen; MiniMark's mark-sweep never moves old-gen objects, and drag_out_root relocates only is_nursery_object_start refs. allocate_stable exists precisely so callers can hold the raw pointer on the Rust stack without rooting it. I did write that "fix" before checking the allocator, then reverted it.